对象过程方法 OPM

Dori定义了对象过程方法（Object Process Methodology，OPM）的正式模式，用于系统开发、生命周期支持和演化。OPM是一种基于模型的系统工程（Model Based Systems Engineering，MBSE）方法论，它将简单、正式的可视化模型对象过程示意图（Object Process Diagrams，OPDs）与带有约束条件的自然语句对象过程语言（Object Process Language，OPL）相结合，实现在一个集成的单个模型中表现系统的功能（设计的系统是用来做什么的）、结构（系统是如何构建的）和行为（系统是如何随时间变化的）。每一个OPD的结构都是由语义等价的OPL语句或者部分语句等进行表示的。OPL是一种面向人机的双重目标语言。

OPM的前提是论域中的所有个体都可归于对象或者过程二者中的某一类。在建模阶段，OPM是在对象、过程和状态这三种实体的基础上进行建立的，其中对象和过程处于更高的层次上，共同称为事物（things），OPM对这些实体进行了正式的定义如下：

对象是存在的，过程表示对象的产生、消耗或者影响的变化模式，而状态并不是独立的，它是用来描述对象的。对象和过程的符号分别用矩形和椭圆来表示，对象（object）和过程（process）名称的首字母通常大写，而且人们更偏好于将过程的名称用动名词的形式来表示（以-ing结尾）表示他们是积极的、动态的事物。状态的符号通常用圆角矩形来表示。状态的名称往往是以小写字母开头的。

图1描述的是一个根据OPM教科书所改编的介绍简要OPD和OPL语句的基本示例。

在这个简单的可视化OPL模型中，从人（Person）连接到男人（Man）和女人（Woman）的开口三角表示人种的分类，而从夫妻（Couple）连接到男人（Man）和女人（Woman）的实心三角表示聚集。具有封闭箭头的线表示输入-输出连接对、消耗链或者由背景所决定的结果链。在这个例子中，从单身（single）状态到结婚（Marrying）过程的连接是一条输入链，从结婚（Marrying）过程到已婚是一条输出链，从结婚（Marrying）过程到夫妻（Couple）是一条结果链。同一条链若具有相反方向（从对象到过程），那么就是一条消耗链。

OPM中将连接分为结构化连接和程序化连接，前者表示系统的对象之间或者过程之间的长期持续关系，后者表示系统的行为。在图1中，输入、输出和结果链是程序化连接，而表示分类和聚集的连接是结构化连接。在同一个示意图中使用结构化和程序化连接，再加上文字叙述，实现了用单一的图形模型对系统进行完整描述的目的。

OPM支持的建模语义远远比上述例子所描述的要丰富得多。关于组成OPDs和OPL语句结构的所有图形元素的语义描述，请读者参考OPM教科书。

图2说明了系统开发过程的一般工作阶段：需求规范、分析和设计、实现以及使用&维护。所有这些过程都使用相同的OPM本体，这可以缩小开发过程的不同阶段之间的分歧。处理需求规范子过程的是客户、系统设计者以及实现者，他们的任务是满足不同用户的需求。需求规范将OPM本体作为输入来生成一个新系统，其中包含一份需求文档。需求规范的终止标志着系统系统开发的下一个子过程——分析和设计的开始。

如图3所示，需求规范阶段包含四个子过程。首先，系统设计者和客户定义了系统（或项目）所要解决的问题，系统需求文档中的问题定义部分是在系统定义这一阶段生成的。接下来通过需求重用子进程，系统设计者可以对符合当前问题的需求进行重用，并对已经存在的系统（由组织所开发的）进行修改。“重用”这一过程可以得到更质量的系统，同时缩短开发和调试时间。因此，当开发较大的系统（如网页应用或实时系统）时，要首先尝试能否对满足当前系统开发的先前版本系统、相似系统或商业现成产品等已经存在的产品进行加工修改实现重用。已经存在且描述较好的需求往往不难获取，因此现存的相关需求不仅仅是代码，更是一种可利用资源。事实上，如OPD所示，可重用的产品不仅包括软件和硬件部分（传统上它们往往是主要的重用目标），需求也可以进行重用。

对现存系统（或项目）的需求选择性重用后，系统设计师和客户共同在其中加入新的需求对其进行更新。为了确保其他可能的OPM工具，特别是OPL编译者，能够对需求文档进行修改，修改是要用OPM本体。由于OPM的双峰性质，特别是OPL作为英语语言（可能是任何自然语言）子集的使用，这使得客户必须积极参与需求描述主要阶段。此外，由于系统设计者和客户用OPM本体来定义新的需求，实际上所得到的需求文档至少有一部分能够用OPL附加其他英文解释来表示的。这种结构化的面向OPM的描述可以将需求文档自动转化为OPM分析和设计框架（即OPD集合及其相应的OPL脚本的框架）。当然，在这一阶段中除了OPM外自然语言的使用对文档的动机、选择和注意事项等来说是起到命令的作用。

最后，需求增补过程会得到Boolean对象“是否需要原路返回？”，这决定了系统开发是否应该重新开始。若需要，则开发过程原路返回会激活整个系统开发的重新进行。否则，需求描述过程结束，开始进行分析和设计过程。

图4描述的是分析和设计阶段的工作过程，主要是根据当前系统的需求文档所建立的。为了使这一阶段尽可能地有效和自动化，需求文档必须用OPM来写，这样得到的OPL脚本可以进行编译。那么，系统设计师就可以有选择性地重用之前系统的分析和设计结果，作为现有系统分析和设计的基础。

最后，通过如图5所示的分析和设计改进过程的迭代，系统设计师可以实现OPL更新、OPD更新、系统驱动、一般信息更新或者分析&设计终止。用户对表示模型的形式所做的任何改动都会引起开发软件环境对新增形式改变的自动回复。因此，OPD更新（由系统设计师完成）对OPD集合有影响，同时立即激活OPL生成，这会根据新的OPL集合来修改OPL脚本。相反地，OPL更新（也是有系统设计师完成）影响着OPL脚本，会激活OPD生成，在OPD集合中反映OPL的改变。

OPM实现了系统动态和控制结构的建模，如事件、条件、分支和环，系统的激活对OPD集合进行仿真，使系统设计者能够对开发的任何阶段进行动态检验。系统行为活跃表现方式的提出减少了实现阶段中的设计错误。静态测试和动态测试有助于进行矛盾、不一致性以及偏离系统设计目标这些问题的检测。作为动态测试的一部分，仿真使设计者在写每一行代码前都能够对系统的每一个场景进行追踪。任何可探测到的错误或者疏忽在建模阶段都会进行校正，节约了在实现阶段所花的时间和精力。在系统开发阶段尽早避免和消除设计错误并保持记录最新对于缩短系统交付时间有重要意义。

在分析&设计改进阶段，如果需要，可以重新开始整个系统开发过程，也可以开始实现阶段。

如图6所示，通过定义实现轮廓来开始实现阶段，包括目标语言（如Java，C++或者SQL）产品的缺省清单。为了生成实现框架，主要用到用当前系统的OPL脚本和内部生成规则。生成规则中储存了大量的OPL语句形式对（模板）和各种目标语言相关的代码模板。

初始实现框架包括系统的结构化和行为化方面，在实现重用和实现改进阶段由实现这进行修改。在测试和调试阶段，根据需求文档对得到的产品进行检测，验证它是否满足客户和系统设计师共同定义的系统需求。如果检测的任何矛盾或错误，系统开发阶段都要重新开始，如果没有就可以最终提交、接受和使用系统。

当进行到使用和维护阶段时，客户会收集最终用到的新的需求用于下一代系统开发的初始阶段。在使用系统时以OPM格式记载新的需求这一机制有利于下一代系统的良好进化。

目前支持OPM建模语言的软件也是由Dori团队开发的OPCAT软件，该产品支持上述关于系统开发阶段的OPM元模型描述的概念。OPCAT能够进行动画仿真、需求管理和以及许多其他的重要特性。